Interesting question

llandale - Tue Jun 05 13:44:51 EDT 2012
I did not try to follow the code. But..

Export functions seem to presume the "current" module, so you can do this first:

• current = m

• current = m
• filtering (off)
• for obj in entire m do
• { reject(obj)
  • if (this obj doesn't qualify, such as isDeleted) then continue
  • if (this obj in in range) then accept(obj)
• }
• filtering(on)
• // m is still "current"
• send m to export

josiah820 - Tue Jun 05 13:53:15 EDT 2012
I think I might have figured it out. I wasn't declaring the new module correctly. However, after I ran it correctly the first time, every other time that I try to run the program, I get an error that says, "create module failed: duplicate item name". I'm assuming that this means that I already created the new module, so I can't recreate it. So does this mean that I need to delete and purge the module that I created? And what code should i use to do that?
Thanks!

josiah820 - Tue Jun 05 13:53:15 EDT 2012
I think I might have figured it out. I wasn't declaring the new module correctly. However, after I ran it correctly the first time, every other time that I try to run the program, I get an error that says, "create module failed: duplicate item name". I'm assuming that this means that I already created the new module, so I can't recreate it. So does this mean that I need to delete and purge the module that I created? And what code should i use to do that?
Thanks!

llandale - Tue Jun 05 16:23:55 EDT 2012
OK missed the part where you are creating a new module and copying objects over. I assume this is for the "convenience" of the export. There is a "hardDelete(ModName_&)" command which you can use on a closed un-deleted module. (If the module is deleted (aka "softDeleted") strangely you need to un-delete it first.)

Yes, of course you cannot create a new module with the same name as the existing one.

Why would you create a new module? Seems to me you cleverly filter the current module and then export that.

-Louie

llandale - Tue Jun 05 16:23:55 EDT 2012
OK missed the part where you are creating a new module and copying objects over. I assume this is for the "convenience" of the export. There is a "hardDelete(ModName_&)" command which you can use on a closed un-deleted module. (If the module is deleted (aka "softDeleted") strangely you need to un-delete it first.)

Yes, of course you cannot create a new module with the same name as the existing one.

Why would you create a new module? Seems to me you cleverly filter the current module and then export that.

-Louie

josiah820 - Wed Jun 06 08:18:15 EDT 2012

Okay, so at the end, if I'm operating on module m, I can just do something like:
 

close(m)
hardDelete(m)

and that should do it for me?

Honestly, I never even thought about the filter thing, but I've already written almost all of the program using the other approach. I'm extremely new with DXL (just started my internship three weeks ago, this is the second week that I've been working with it,) so I'm still getting into the swing of it. I really appreciate all of your help!

llandale - Wed Jun 06 17:12:19 EDT 2012
after you close "m", that handle is corrupt but not erased. You will get serious exceptions when you use "m" perhaps 1 second after closing it. In any event, the "hardDelete" takes a variable of type "ModName_", which I'm pretty sure you need to read about in the DXL manual.

• hardDelete(module(NameModuleFull))

PatrickGuay - Thu Jun 07 10:13:11 EDT 2012
Just a suggestion... you do not need to put a line of comment on each line of code. Just place comments for tricky sections of code or for maintainability. If you place a hack in your code this may be another good reason for comments.

PatrickGuay - Thu Jun 07 10:13:11 EDT 2012
Just a suggestion... you do not need to put a line of comment on each line of code. Just place comments for tricky sections of code or for maintainability. If you place a hack in your code this may be another good reason for comments.

llandale - Thu Jun 07 12:50:05 EDT 2012

Comment theory.

Without a doubt, the purpose of comments is to make the code easier to understand. The inescapable fundamental facts of comments are these realities:

1. Code not immediately understandable is easier to understand with reasonable comments; and
2. Perfectly understandable code is harder to understand with any comments. The comments distract the reader away from the code.

[2] has the meaning that the physical existance of comments (such as if some other language) obscures the code.

I assert the following primary guidance:

• What is and what is not a comment should be readily discernable without reading it. For folks with good eyes, imagine putting on strong reading glasses to obscure the letters; you should be able to point to what is code and what is comments, even if you cannot read it.

This mostly resolves these conflicting needs..

1. need for more comments to help inexperienced folks or folks first reading this code; and
2. need for less comments for experienced folks familiar with the code.

Perhaps a minority opinion, but I find it repugnant when I see comments deliberately placed at the same indentation level of the code:

// define skip list for Objects
Skip skpObjects = null
// create the object skip list
skpObjects = createString
   .... Surely this is far easier to read:
Skip skpObjects = null      // define skip list for Objects
skpObjects = createString  // create the object skip list

And I would also like to say that the above particular comments are useless and detrimental; they add no understanding to the code.

Skip skpObjects = null       // Key is Identifier, Data is 'Object' handle
skpObjects = createString

I therefore make reasonable effort to line up my comments with some serious indention; perhaps the majority start in column 50. There are times that I add indention level to comments, to match indention of the code. I usually start the comment in the same column, but start the text of the comment further right.

A problem with a philosophy of "comment the tricky, do not comment the mundane" is that what is "mundane" for the author is usually "tricky" for the reader.

I suggest that decisions about comments should be less whether "it's true" and more whether "it's useful".

-Louie

josiah820 - Thu Jun 07 14:14:23 EDT 2012

Okay, I've taken all of your suggestions. After I actually had the objects exporting to the new module, I realized that the "Last Modified On" attribute (as long as the DOORS ID #) would be completely different in the new module. This was a major problem, so I switched my approach to using a Filter. I think that I have it working perfectly, except for one thing: On lines 82-85, I have:

Filter f1 = attribute "Last Modified On" >= "date1"
Filter f2 = attribute "Last Modified On" <= "date2"
Filter f3 = f1 && f2
set(l,f3)

where "l" is the module that I am operating the filter on. "date1" and "date2" are set to equal "a" and "b" respectively, which are taken from the parameters needed for the export function. When I call "export," I pass two date variables collected from a DBE box, to the export function. For some reason, both date1 and date2 are giving me errors that say, "illegal value '(date1 or date2)' for type 'Date'.
What does this mean? I have clearly defined date1, date2, a, and b as "Date" variables, and I have AutoDeclare turned off. I really think that this is the only thing standing between me and completing this program.

SystemAdmin - Thu Jun 07 15:07:49 EDT 2012

"date1" cannot be correct as this is a literal string containing exactly these characters.

You will need a string representation of the date to compare against.
Try something like the following, you may have to fiddle with the locale and the accepted format
 

Locale l = locale (1033) // EN (US)
string s1 = stringOf (date1,l, "dd MMMM yyyy")
string s2 = stringOf (date2,l, "dd MMMM yyyy")
 
 
Filter f1 = attribute "Last Modified On" >= s1
Filter f2 = attribute "Last Modified On" < s2

josiah820 - Thu Jun 07 08:19:05 EDT 2012
Would there be any way that I could, like, clear all of the items that I made previously? I tried a complete purge, but I'm still getting a "duplicate item name," even if I never used the item name before? This is really weird.

Yeah, I didn't have much of an issue with most of the loops and stuff. I'm actually fairly fluent in java, so my main problem is translating into DXL from what I'm used to. I really appreciate all of your help!!

oaklodge - Fri Jul 26 03:11:18 EDT 2013

I realize this is more than a year later and I can't remember what I had for lunch yesterday, but did you ever figure out what was causing the "create module failed: duplicate item name" error? Thanks.